Secure Bridging of Third-Party Digital Rights Management to Local Security

ABSTRACT

Encrypted content from a content provider is received at a headend of a video programming distributor. The content provider is distinct from the video programming distributor. The content is decrypted and modified by blending a user-interface overlay with the content in a virtual set-top application associated with a set-top of a customer of the video programming distributor. The modified content is provided over a secure data link to a conditional-access encoder at the headend. The conditional-access encoder encrypts the processed content, which is then transmitted to a client device.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/261,791, filed Sep. 9, 2016, now U.S. Pat. No. ______, entitled,“Secure Bridging of Third-Party Digital Rights Management to LocalSecurity,” which claims priority to U.S. Provisional Patent ApplicationNo. 62/217,529, filed Sep. 11, 2015, which is incorporated by referenceherein in its entirety.

TECHNICAL FIELD

The present disclosure relates generally to content-delivery systemsand, more particularly, to digital-rights management (DRM) licenseenforcement on distributed networks.

BACKGROUND

Cable content providers and distributors have developedcontent-distribution services in an attempt to compete with the emergingmarket trend of “cord cutting”, in which consumers discontinuetraditional pay television subscriptions for programming delivered bymultichannel video programming distributors (MVPD), such as cable andsatellite TV companies or companies that perform multichannel videodistribution over the Internet, in favor of accessing television contentgenerally through online media services such as Hulu, Netflix, orYouTube. In an effort to compete with these Internet-delivered contentproviders, the MVPDs offer their own on-demand services to both thetraditional set-top as well as to mobile devices such as tablets andsmartphones. Sometimes called “TV Everywhere,” such authenticatedstreaming and video-on-demand services from MVPDs allow these televisionproviders (i.e., the MVPDs) to compete with Internet-delivered providerswith the goal of retaining subscribers.

MVPD providers use “TV Everywhere” services to provide multiplatformaccess to their content on a wide variety of devices to cater tochanging consumer tastes. However, the most profitable content remainsthe digital release, in high-definition, of feature films available toconsumers on a pay-per-view or pay-per-day basis in the movie'srespective digital release window. Such valuable content is considered aprime target for piracy. Content owners therefore require highly robustDigital Rights Management (DRM) content-protection safeguards to ensurethat the specific consumer device requesting protected content, whethera TV set-top, Internet-connected set-top, or mobile device, isauthorized to view the protected content before allowing the device todecode and play the protected content.

DRM software that is robust enough to be trusted by movie studios andother owners of high-value content is complex and computationallyintensive. Examples of such software include PlayReady from Microsoftand WideVine from Google. Personal computers and tablets typically havethe processing power to manage these complex security measures. OtherDRM applications have been devised that will run in some smartphoneenvironments. However, the computational power available in the typicalMVPD-supplied legacy set-top box is based on old technology (e.g., adecade or two old) and incapable of running the DRM applicationenvironment required by the content owner.

A “DRM bridge” solution may be implemented in which a central serverplatform terminates and decodes DRM-protected content and then passesthe content in the clear to an MVPD's conditional-access (CA) system,where the content is re-encrypted for further distribution on the MVPD'snetwork. It is not a simple matter, however, for content owners toaccept such a solution. Certain DRM bridge solutions have a security“gap” that occurs as the raw content is exposed between the moment it isdecrypted from the approved commercial DRM system and the moment it isre-encrypted in the MVPD's CA format. This gap can allow a securitybreach, whether by hacking into the cable system's headend network overthe Internet or possibly by an employee or ex-employee who retainsaccess codes or has knowledge of “back doors” into thecontent-distribution network.

It is therefore in the interest of MVPD operators to deliverInternet-originated but protected content to their customers'televisions. The convenience of delivery of Internet content to theconsumer's television (typically the consumer's largest display screen),via the cable set-top, provides an opportunity to retain customerloyalty and reduce cord-cutting.

SUMMARY

Accordingly, there is need for a centralized DRM solution that providesend-to-end encryption of media assets, from the content-delivery network(CDN) down into the client device that secures content with a robustnessthat is acceptable to the content owner.

Content is distributed from one or more DRM-protected systems via adistribution network to a central location (e.g., a cable TV headend orhub). One or more DRM systems in the central location are securelybridged to the content protection system of a distribution network overwhich the central location transmits content. The content may arrive atthe central location protected by a commercial DRM typically used forInternet media distribution such as for feature films or televisionprogramming. In some embodiments, media protected by the DRM isconverted to the cable television system's conditional-access (CA)system for distribution to one or more cable set-top devices(“set-tops”), which decode the content in a manner consistent with otherprotected content (e.g., video-on-demand (VoD) or pay-per-view (PPV)content) as distributed by the system. The translation of high-valuemedia from one DRM system to another DRM system (e.g., the CA system) isaccomplished in a secure computing environment where protected contentis not exposed to potential theft.

This bridging system maintains security of all content entrusted to itvia a third-party DRM-protected system, and then re-encrypts the contentin the MVPD's CA format while maintaining end-to-end entertainmentindustry-required safeguards against piracy. The bridging systemaddresses the problem of securely converting commercially-valuable mediafrom robust, third-party Digital Rights Management encryption formatswidely used by Internet-based content providers to the CA protectionformat used by MVPDs to deliver high-value content to their payingsubscribers via their respective content distribution networks.

In some embodiments, a method is performed at a central location of aMVPD. In the method, encrypted content is received from a contentprovider that is distinct from the MVPD. The encrypted content isdecrypted and processed in a virtual set-top application associated witha set-top of a customer of the MVPD. The set-top of the customer islocated in a customer premises remote from the central location. Theprocessed content is provided over a secure data link to aconditional-access encoder and encrypted using the conditional-accessencoder. The processed content as encrypted by the conditional-accessencoder is transmitted to the set-top of the customer.

In some embodiments, an electronic system includes a secure applicationserver with one or more processors and memory storing one or moreprograms configured to be executed by the one or more processors. Theone or more programs included instructions for receiving encryptedcontent from a content provider, wherein the content provider isdistinct from a MVPD associated with the secure application server;decrypting the encrypted content; and processing the decrypted contentin a virtual set-top application associated with a set-top of a customerof the MVPD, wherein the set-top of the customer is located in acustomer premises remote from the secure application server. Theelectronic system also includes a conditional-access encoder to encryptthe processed content for transmission to the set-top of the customerand a secure data link to convey the processed content from the secureapplication server to the conditional-access encoder.

In some embodiments, a non-transitory computer-readable storage mediumstores one or more programs for execution by one or more processors of asecure application server at a central location of a MVPD. The one ormore programs include instructions for receiving encrypted content froma content provider, wherein the content provider is distinct from theMVPD; decrypting the encrypted content; processing the decrypted contentin a virtual set-top application associated with a set-top of a customerof the MVPD, wherein the set-top of the customer is located in acustomer premises remote from the central location; and providing theprocessed content over a secure data link to a conditional-accessencoder for encryption and transmission to the set-top of the customer.

The secure bridging disclosed herein provides an end-to-end securestreaming architecture in which multiple third-party vendor's DRMsystems can provide protected delivery of valuable audio/video contentto a common set-top device in a consumer's home. The bridgingarchitecture provides secure storage of security-related key material ina centralized storage for the various third-party DRM credentials.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the various described embodiments,reference should be made to the Detailed Description below, inconjunction with the following drawings. Like reference numerals referto corresponding parts throughout the figures and description.

FIG. 1 is a flow diagram of steps for obtaining encrypted content viathe Internet, unencrypting and processing the content, and re-encryptingthe content in a network-standard encryption process for transmission toa network-compatible set-top for decrypting and display, in accordancewith some embodiments.

FIG. 2 is a block diagram of a system in which content flows fromthird-party providers through a protected environment to a televisionsystem connected to a distribution network, in accordance with someembodiments.

FIG. 3 is a block diagram of an example of portions of the system ofFIG. 2 in accordance with some embodiments.

FIG. 4 is a block diagram of a secure application server and itsinterfaces to surrounding systems, in accordance with some embodiments.

FIG. 5 is a block diagram showing content-security elements from theheadend to the set-top, in accordance with some embodiments.

FIG. 6 shows an Extensible Media Rights (XMR) header data structure thatdefines a data record structure in XML format for communicating DRMinformation between trusted computing elements, in accordance with someembodiments.

FIG. 7 is a block diagram illustrating a secure application server inaccordance with some embodiments.

DETAILED DESCRIPTION

Reference will now be made to certain embodiments, examples of which areillustrated in the accompanying drawings. In the following description,numerous specific details are set forth in order to provide anunderstanding of the various described embodiments. However, it will beapparent to those of ordinary skill in the art that the variousdescribed embodiments may be practiced without these specific details.In other instances, well-known systems, methods, procedures, components,circuits, and networks have not been described in detail to avoidunnecessarily obscuring aspects of specific embodiments.

FIG. 1 shows a flow of content in accordance with some embodiments. Athird-party secure content provider 101 delivers encrypted content(e.g., including video, audio, and/or still images) via the Internet 102to a decryption process 103 that runs in a protected environment (e.g.,a secure application server). The protected environment is typicallylocated in a processing center (e.g., headend) of a multichannel videoprogramming distributor (MVPD), which is typically known to televisionconsumers as their cable-TV or satellite-TV company. The content isprocessed in a virtual set-top application 104 (also known as a virtualset-top client or virtual set-top) in an unencrypted form (i.e., “in theclear”). Such processing may include scaling of the video image to fitin a window of a user-interface screen and/or the application ofuser-interface overlay graphics for such purposes as the display of amovie purchase screen or the display while viewing content of a virtualtransport control process such as a simulated fast-forward, rewind,play, and pause controller. The processed content is provided to theMVPD's distribution network via a secure conveyance 105 using, forexample, virtual private networking (VPN). Encryption and routing areapplied to the content (e.g., to the service stream) in an MVPD network106 in preparation for transmitting the content via the distributionnetwork 107 to one or more receiving devices such as a set-top 108,which performs decryption and decoding.

FIG. 2 illustrates a system with components that implement the steps ofFIG. 1 in accordance with some embodiments. Third-party contentproviders 101 a, 101 b deliver encrypted content via the Internet 102 toan MVPD's central facility 220, which includes a secure applicationserver 208 and a MVPD network 106. A decryption process 103 in thesecure application server 208 decrypts the content and provides it to avirtual set-top 104, which processes the decrypted content. The secureapplication server 208 may have the capacity to support multiplesimultaneous users (e.g., 100 or more users) and may implement (i.e.,instantiate) a virtual set-top for each user.

The server 208 transmits its output to the MVPD network 106 via a secureconveyance (i.e., secure data link) 105. For example, an encryptionprocess 207 in the secure application server 208 encrypts data output bythe virtual set-top 104 and transmits the encrypted data over acommunication channel to the MVPD network 106, where a decryptionprocess 209 decrypts the data. In some embodiments, the secure data link105 is implemented using a virtual private network (VPN) protocol (e.g.,across a standard Ethernet link). Alternatively, the secure data link105 is implemented using a dedicated link.

The MVPD network 106 performs network routing 210 and re-encodes thedata using an encryption scheme 211 compatible with the set-top boxes108 connected to the distribution network 107. The encryption scheme 211is generally referred to as a conditional access (CA) system, which iscompatible with the manufacturer of the set-tops 108 deployed by theMVPD. Examples of set-top manufacturers include Motorola (Arris) andScientific Atlanta, among others.

FIG. 3 is a block diagram showing an example of the system of FIG. 2, inaccordance with some embodiments. In the example of FIG. 3, thedecryption process 103 (FIGS. 1-2) is implemented with a third-partyapplication engine 303 in the secure application server 208. Thethird-party application engine 303 provides secure decryption ofprotected media content received from a third-party content provider 101and feeds the decrypted content to a virtual set-top 104, which providesoutput to a router 304. The router 304 is linked through a VPN 305 to areceiving VPN 306 via a link 309 (e.g., a wired link, such as a wiredEthernet link). Any secure communications that can convey digital mediaat suitable speeds could also serve as the link 309. The receiving VPN306 provides data (e.g., digital media and other data) to a router 307,which sends the data to MVPD conditional-access encoders 313. The router304, VPN 305, link 309, receiving VPN 306, and router 307 compose abridged private network 312, which is an example of a secure conveyance(i.e., secure data link) 105. The MVPD CA encoders 313 implement thesecure encryption scheme 211 in accordance with some embodiments. TheMVPD CA encoders 313 provide encrypted data to a MVPD distributionnetwork 308, which forwards the encrypted data to its destination. TheMVPD CA encoders 313, router 307, and receiving VPN 306 compose a securedistribution network 311, which together with the MVPD distributionnetwork 308 is an example of the MVPD network 106 (FIGS. 1-2).

FIG. 4 shows a content-streaming (i.e., media-streaming) architecture ofthe secure application server 208 in accordance with some embodiments.An embedded browser 401 (i.e., a server-side browser) (e.g., a Webkitbrowser, such as a Webkit-based cloud browser) in the secure applicationserver 208 communicates with a third-party media provider 101 via astream-control link 402 and receives a media stream 403 (i.e., a contentstream, which includes video, audio, and/or images) from acontent-distribution network (CDN). The embedded browser 401 executes anHTML5 application 404. (In some embodiments, the embedded browser 401runs the third-party application engine 303, FIG. 3.) In someembodiments, the HTML5 application 404 uses open-source MediaSource oranother resource that extends the HTML5 environment to allow script(e.g., JavaScript) to generate media streams for playback. AllowingJavaScript to generate streams facilitates use cases such as adaptivestreaming and time-shifting live streams.

A keybox 406 stores one or more keys used to decrypt the received mediastream 403. For example, a private key stored in the keybox 406 is usedin conjunction with a public key held by the HTML5 application 404 todecrypt the received media stream 403. A content decryption module (CDM)405 is used to access the keybox 406. In some embodiments, an EncryptedMedia Extension (EME) API is used to allow the HTML5 application 404 tointeract with the CDM 405 to decrypt the received media stream 403. EMEis an HTML5 extension that provides an API to enable web applications tointeract with content-protection systems. In some embodiments, the HTML5application 404 uses scripted routines (e.g., JavaScript softwareroutines) to fetch the media stream 403. The HTML5 application 404 mayuse MPEG-DASH, HLS, or any other transport mechanism of its choice. Insome embodiments, the HTML5 application 404 writes media data for themedia stream 403 into a media buffer (e.g., using APIs) and monitorsbuffer levels to decide when there is sufficient data to start mediaplayback.

The embedded browser 401 runs as part of a virtual set-top process 415(e.g., virtual set-top 104) on the secure application server 208. Insome embodiments, the virtual set-top process 415 supports multipleinstances of virtual set-tops 104, each with a distinct correspondinginstance of the HTML5 application 404 and CDM 405. The multipleinstances of the CDM 405 all access a single keybox 406. In someembodiments, the embedded browser 401 (e.g., the HTML5 application 404)includes a media player that detects whether or not the media stream 403is encrypted and, if it is encrypted, selects the proper ContentDecryption Module (CDM) 405 for the corresponding digital rightsmanagement system (DRM) previously used (e.g., by the third-partycontent provider 101) to encrypt the media stream 403. The secureapplication server 208 thus may include multiple CDMs 405, eachcorresponding to a distinct DRM system/protocol. The CDM 405 creates asecurity-key request message that is transmitted to a corresponding keyserver associated with (e.g., operated by) a third-party contentprovider 101. The key server responds with the requested security key,which is stored in the keybox 406. This retrieval of the key may bereferred to as a key handshake. Before the key handshake, authenticationof the secure application server 208 with the third-party contentprovider 101 (e.g., with the content-distribution network) may beperformed. If authentication and the key handshake are successful, theCDM 405 decrypts the media stream 403 and sends it to a streaming engine416. The streaming engine 416, like the virtual set-top process 415, isexecuted by the secure application server 208.

In some embodiments, the streaming engine 416 switches between threemodes: (1) stitching of user-interface (UI) fragments when nofull-screen video is visible (e.g., available), (2) pass-through ofvideo, or (3) transcoding of full-screen video. For example, in thefirst mode a first MPEG encoder 408 encodes UI fragments into a UI andprovides the UI to a second MPEG encoder 409, which re-encodes the UI toscale the video in accordance with the destination set-top 108. Thefirst mode may be performed when no full-screen video is visible. In thesecond mode (i.e., pass-through mode), a third MPEG encoder 410 encodesvideo provided (e.g., in bitmap format) by the CDM 405. The pass-throughmode is selected when the corresponding set-top 108 (i.e., clientdevice) is capable of decoding the video data (e.g., supports therelevant codec, aspect ratio, frame rate, and resolution). In the thirdmode, a fourth MPEG encoder 411 transcodes full-screen video (asdecrypted from the media stream 403 by the CDM 405) and optionallyoverlays bitmaps. The bitmaps are provided by a bitmap encoder 407,which generates the bitmaps based on output from the embedded browser401. The third mode is selected when corresponding set-top 108 (i.e.,client device) is not capable of decoding the video data or when a UIoverlay is to be rendered on top of the full-screen video. The accessthat the streaming engine 416 has to the unencrypted video data 413allows it to blend UI overlays with the video data 413. In the secondand third modes, the streaming engine 416 re-multiplexes,resynchronizes, and re-streams the original decrypted video stream 413,which is encrypted by an encryption process 412 (e.g., by the secureencryption scheme 211, FIG. 2) (e.g., in a CA encoder 313). Theencryption process 412 outputs an encrypted video stream 418. The videostream 418 is an example of a content stream.

In some embodiments, if the set-top 108 (i.e., client device) at thedestination supports overlay rendering with sufficient quality, thesystem may send the overlay bitmaps 414 to the set-top 108 rather thanusing hardware transcoding resources (e.g., MPEG encoder 411) on thesecure application server 208. For example, the overlay bitmaps are sentto the set-top 108 in the clear (i.e., unencrypted) separately from theencrypted video stream 418.

In some embodiments, the output of the streaming engine 416 is sent as aclear (i.e., unencrypted) MPEG2 transport stream (MPEG-TS) over UDP tothe MVPD network 106. The connection from the streaming engine 416 tothe MVPD network 106 can be achieved, for example, via a secure virtualprivate network connection (e.g., in the bridged private network 312,FIG. 3) or other secure connection, such that valuable content is nevertransmitted “in the clear” even within the facilities (e.g., headend) ofthe MVPD. The MVPD network 106 encrypts the video stream (e.g., usingencryption scheme 211, FIG. 2) before sending it to the set-top 108,using the MVPD's Conditional Access system (e.g., CA encoder 313, FIG.3). In some embodiments, three models are supported for encryption bythe CA system: (1) a session manager (e.g., executed by the secureapplication server 208) interfaces with the MVPD network 106 (e.g.,using the SimulCrypt EIS-SCS protocol) to request encryption of thecontent stream to securely send the content stream to an authorizedset-top 108 capable of decrypting the content stream; (2) the sessionmanager interacts with a MVPD session resource manager (SRM) (e.g.,executed by the secure application server 208) to request a networkresource that has encryption enabled. The SRM then interacts with the CAsystem to enable encryption; (3) The MVPD configures common encryptionon the network transmission system, ensuring that all streams on acertain network path (e.g., a path within the distribution network 107)are encrypted. The configuration in the third model is a staticconfiguration and requires no messaging between the session manager andthe MVPD network 106.

In some embodiments, the keybox 406 (FIG. 4) contains devicecertificates, access tokens, and/or other secrets (e.g., private keys)used by the CDM 405. Such data is treated, for example, as anunstructured data object, sometimes referred to as a ‘blob’. In someembodiments, such as for the Widevine CDM, a key in the keybox 406 isprovisioned in encrypted (i.e., wrapped) format and is only present inclear-text (i.e., in an unencrypted format) inside the CDM 405 itself.

Requirements for secrecy and non-mutability of these data items may bestated in so-called “robustness rules” that apply to set-top boxmanufacturers as well as third parties that pass or otherwise controlvaluable encrypted content. These rules specify whether or not it isacceptable that a data item is read, modified, or duplicated given acertain set of system tools. Content providers are justifiably concernedabout unauthorized service hacks by any consumer who can obtain aset-top 108 and, hence, must be considered a potential adversary.

When moving the playback application to the cloud in accordance withembodiments disclosed herein, the application is not executed in aconsumer premise (a hostile environment from a security perspective),but instead runs on an operator network environment that is consideredsecure in terms of protection against physical and network access fromoutside intruders. From this perspective, the data is consideredprotected against common threats. Also, consumers (i.e., end-users) areno longer considered an adversary, because it becomes difficult for themto access secret data. As such, many of the robustness rules are met bymoving the data items into the protected operator network (e.g., bystoring them in the keybox 406). On the other hand, the data is storedin bulk on network servers rather than on individual flash memories onmany thousands of set-top boxes. This bulk storage makes it easier foran intruder, especially from an insider (e.g., an employee) to getaccess to bulk data and hence may result in the imposition of additionalsecurity requirements on data storage, which may not be specified in therobustness rules.

FIG. 5 shows content-security processes and interconnections from theheadend to the set-top in accordance with some embodiments. Securecontent 523 from a third-party content provider 101 arrives at anapplication engine 520 (e.g., as executed by a secure application server208) and is decrypted using the CDM 521 (e.g., CDM 405, FIG. 4) by avirtual set-top 522 (e.g., virtual set-top 104). The content then passesthrough a secure router/VPN link 531 to router/VPN 512 in the MVPDNetwork 510, which feeds the content to MVPD CA encoder 511 (e.g., CAencoder 313). The CA encoder 511, which is also in the MVPD Network 510,encrypts and thus re-secures the content stream for transmission to oneor more client devices 500 (e.g., set-tops 108).

A media player 501 in a client device 500 processes the received contentstream. A MVPD conditional access process 502 of the media player 501decrypts the content stream by applying a license 503 to a CA decryptprocess 504. The decrypted content is presenting to a stream player 505,which decodes the content (i.e., media) and sends the decoded content toa connected display device (e.g., an HDTV monitor).

FIG. 6 shows an Extensible Media Rights (XMR) header structure defininga data record structure 600 in XML format for communicating DRMinformation between trusted computing environments, in accordance withsome embodiments. For example, the data record structure 600 is used formessages sent between set-tops 108 and the secure application server 208and/or between the secure application server 208 and CDNs forthird-party content providers 101. The data record structure 600includes one or more XMR container objects 601 and an XMR signatureobject 611. Each XMR container object 601 includes a global policycontainer object 602, playback policy container object 606, copy policycontainer object 607, and key material container object 608. The globalpolicy container object 602 includes a revocation information versionobject 603, global rights setting object 604, and minimum environmentobject 605. The key material container object 608 includes a content keyobject 609 and RSA device key object 610. An object that is not relevantto or absent from a particular message may be omitted from the message.

Disclosed embodiments provide secure and efficient online videoservices, such as video services that use standardized W3C technologies(e.g., HTML5, MediaSource, and Encrypted Media Extensions). Webapplications may be run without modifications in accordance with someembodiments. Valuable content is securely conveyed in audio and/or videoformats to set-top devices in consumer premises (e.g., the consumer'shome), where a set-top with only an MVPD's general-purposeconditional-access capability can access any content from online videoproviders while maintaining content security.

The functionality described herein, for the server and/or the client,may be embodied in many different forms, including by way of exampleonly but in no way limited to, computer program logic for use with aprocessor (e.g., a microprocessor, microcontroller, digital signalprocessor, or general purpose computer), programmable logic for use witha programmable logic device (e.g., a Field Programmable Gate Array(FPGA) or other PLD), discrete components, integrated circuitry (e.g.,an Application Specific Integrated Circuit (ASIC)), or any other meansincluding any combination thereof.

Computer program logic implementing all or part of the functionalitypreviously described herein may be embodied in various forms, including,by way of example only but in no way limited to, a source code form, acomputer executable form, and various intermediate forms (e.g., formsgenerated by an assembler, compiler, linker, or locator). Source codemay include a series of computer program instructions implemented in anyof various programming languages (e.g., an object code, an assemblylanguage, or a high-level language such as Fortran, C, C++, JAVA, orHTML) for use with various operating systems or operating environments.The source code may define and use various data structures andcommunication messages. The source code may be in a computer executableform (e.g., via an interpreter), or the source code may be converted(e.g., via a translator, assembler, or compiler) into a computerexecutable form.

The computer program may be fixed in any form (e.g., source code form,computer executable form, or an intermediate form) either permanently ortransitorily in a tangible storage medium, such as a semiconductormemory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-ProgrammableRAM), a magnetic memory device (e.g., a diskette or fixed disk), anoptical memory device (e.g., a CD-ROM), a PC card (e.g., PCMCIA card),or other memory device. The storage medium may be a non-transitorycomputer-readable storage medium (e.g., nonvolatile memory). Thecomputer program may be fixed in any form in a signal that istransmittable to a computer using any of various communicationtechnologies, including, but in no way limited to, analog technologies,digital technologies, optical technologies, wireless technologies (e.g.,Bluetooth), networking technologies, and internetworking technologies.The computer program may be distributed in any form as a removablestorage medium with accompanying printed or electronic documentation(e.g., shrink wrapped software), preloaded with a computer system (e.g.,on system ROM or fixed disk), or distributed from a server over acommunication system (e.g., the Internet or World Wide Web).

Hardware logic (including programmable logic for use with a programmablelogic device) implementing all or part of the functionality previouslydescribed herein may be designed using traditional manual methods, ormay be designed, captured, simulated, or documented electronically usingvarious tools, such as Computer Aided Design (CAD), a hardwaredescription language (e.g., VHDL or AHDL), or a PLD programming language(e.g., PALASM, ABEL, or CUPL).

Programmable logic may be fixed either permanently or transitorily in atangible storage medium, such as a semiconductor memory device (e.g., aRAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memorydevice (e.g., a diskette or fixed disk), an optical memory device (e.g.,a CD-ROM), or other memory device. The programmable logic may be fixedin a signal that is transmittable to a computer using any of variouscommunication technologies, including, but in no way limited to, analogtechnologies, digital technologies, optical technologies, wirelesstechnologies (e.g., Bluetooth), networking technologies, andinternetworking technologies. The programmable logic may be distributedas a removable storage medium with accompanying printed or electronicdocumentation (e.g., shrink wrapped software), preloaded with a computersystem (e.g., on system ROM or fixed disk), or distributed from a serverover the communication system (e.g., the Internet or World Wide Web).

FIG. 7 is a block diagram illustrating a secure application server 700(e.g., secure application server 208) in accordance with someembodiments. The secure application server 700 includes one or moreprocessing units (processors or cores) 702, one or more network or othercommunications interfaces 704, memory 708, and one or more communicationbuses 706 for interconnecting these components. The secure applicationserver 700 optionally includes a user interface (not shown).

Memory 708 includes volatile and non-volatile memory and may optionallyinclude one or more storage devices remotely located from the processingunits 702. Memory 708, or alternately non-volatile memory within memory708, includes a non-transitory computer-readable storage medium. In someembodiments, memory 708 or the computer-readable storage medium ofmemory 708 stores the following programs, modules and data structures,or a subset or superset thereof:

-   -   an operating system 710 that includes procedures for handling        various basic system services and for performing        hardware-dependent tasks;    -   a network communication module 312 for connecting the secure        application server 700 to other computers via the one or more        communication network interfaces 304 (wired or wireless) and one        or more communication networks;    -   a decryption module 714 (e.g., decryption process        103/third-party application engine 303);    -   a virtual set-top application 716 (e.g., virtual set-top        application 104/virtual set-top process 415), including for        example:        -   an embedded browser 718 (e.g., embedded browser 401),        -   a CDM 720 (e.g., CDM 405), and        -   a keybox 722 (e.g., keybox 406);    -   a streaming engine 724 (e.g., streaming engine 416); and    -   an encryption module 726 (e.g., encryption process 207),        including for example:        -   a router 728 (e.g., router 304), and        -   a VPN 730 (e.g., VPN 305).

Each of the above identified modules, applications, and enginescorrespond to a set of executable instructions for performing one ormore functions as described above and/or in the methods describedherein. These sets of instructions need not be implemented as separatesoftware programs, procedures or modules, and thus various subsets are,optionally, combined or otherwise re-arranged in various embodiments. Insome embodiments, memory 708 stores a subset of the items identifiedabove. Furthermore, memory 708 optionally stores additional items notdescribed above.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the scope of the claims to the precise forms disclosed. Manymodifications and variations are possible in view of the aboveteachings. The embodiments were chosen in order to best explain theprinciples underlying the claims and their practical applications, tothereby enable others skilled in the art to best use the embodimentswith various modifications as are suited to the particular usescontemplated.

Acronym Expander Table   API—Application Programing InterfaceCDN—Content Delivery Network CDM—Content Decryption Module DRM—DigitalRights Management MVPD—Multichannel Video Programming DistributorTEE—Trusted Execution Environment VPN—Virtual Private NetworkXMR—Extensible Media Rights

What is claimed is:
 1. A method, comprising: at a headend of a videoprogramming distributor hosting a plurality of virtual set-topapplications, each virtual set-top application corresponding to a clientdevice: at a first virtual set-top application of the plurality ofvirtual set-top applications, the first virtual set-top applicationcorresponding to a first client device: receiving encrypted content froma content provider, wherein the content provider is distinct from thevideo programming distributor; decrypting the encrypted content inaccordance with a first Digital Rights Management (DRM) protocol used bythe content provider; modifying the decrypted content, includingblending a user-interface overlay, provided by a playback applicationexecuting at the headend of the video programming distributor, with thedecrypted content to generate a new data stream; and at a videoprogramming distributor network: determining a second DRM protocolcompatible with the first client device; encrypting, via aconditional-access encoder, the new data stream using the second DRMprotocol compatible with the first client device; and transmitting, tothe first client device, the data as encrypted by the conditional-accessencoder.
 2. The method of claim 1, further comprising: at the firstvirtual set-top application, after modifying the decrypted content togenerate the new data stream: encrypting the new data streamcorresponding to the modified decrypted content from the contentprovider; transmitting the encrypted new data stream over a secure datalink from the first virtual set-top application to the video programmingdistributor network; and at the video programming distributor network:decrypting the encrypted new data stream to generate decrypted data;sending the decrypted data to the conditional-access encoder, whereinencrypting the new data stream comprises encrypting the decrypted data.3. The method of claim 2, wherein the encrypted new data stream istransmitted via a local network.
 4. The method of claim 2, wherein theencrypted new data stream is transmitted via a wired Ethernet link. 5.The method of claim 2, wherein the secure data link comprises a bridgedprivate network.
 6. The method of claim 1, wherein the playbackapplication comprises an HTML5 application.
 7. The method of claim 1,wherein receiving the encrypted content, decrypting the encryptedcontent, and modifying the decrypted content are performed in a secureapplication server at a central location.
 8. The method of claim 7,wherein decrypting the encrypted content is performed using a key from asecure keybox in the secure application server.
 9. The method of claim1, wherein receiving the encrypted content from the content providercomprises receiving the encrypted content from a content-distributionnetwork associated with the content provider.
 10. The method of claim 9,wherein the encrypted content is received from the content-distributionnetwork via the Internet.
 11. The method of claim 1, wherein theencrypted content comprises encrypted video.
 12. The method of claim 11,wherein the method further comprises processing the decrypted content toscale the video to fit a window of a screen.
 13. The method of claim 1,wherein the video programming distributor is a cable-TV company or asatellite-TV company.
 14. The method of claim 1, wherein the headend ofthe video programming distributor distributes the data as encrypted bythe conditional-access encoder via the Internet.
 15. The method of claim1, wherein the encrypted content comprises encrypted audio.
 16. Themethod of claim 1, wherein the encrypted content comprises an encryptedimage.
 17. The method of claim 1, wherein the virtual set-topapplication is executed by a secure application server.
 18. The methodof claim 1, further comprising: at a second virtual set-top applicationcorresponding to a second client device: receiving second encryptedcontent from the content provider; decrypting the second encryptedcontent in accordance with the first Digital Rights Management (DRM)protocol used by the content provider; determining that the secondclient device supports user-interface overlay rendering; upondetermining that the second client device does support user-interfaceoverlay rendering: re-encrypting the second decrypted content from thecontent provider; transmitting the re-encrypted second content over asecure data link from the second virtual set-top application to thevideo programming distributor network; at the video programmingdistributor network: decrypting the re-encrypted second content togenerate decrypted second data; determining a third DRM protocolcompatible with the second client device; encrypting, via theconditional-access encoder, the decrypted second data using the thirdDRM protocol compatible with the second client device; and transmitting,to the second client device (i) the second data as encrypted by theconditional-access encoder, and (ii) at least one user-interface overlaythat has not been encrypted using the third DRM protocol.
 19. Anelectronic system, comprising: a secure application server of a videoprogramming distributor hosting a plurality of virtual set-topapplications, each virtual set-top application corresponding to a clientdevice, comprising one or more processors and memory storing one or moreprograms configured to be executed by the one or more processors, theone or more programs including instructions for: at a first virtualset-top application of the plurality of virtual set-top applications,the first virtual set-top application corresponding to a first clientdevice: receiving encrypted content from a content provider, wherein thecontent provider is distinct from the video programming distributor;decrypting the encrypted content in accordance with a first DigitalRights Management (DRM) protocol used by the content provider; modifyingthe decrypted content, including blending a user-interface overlay,provided by a playback application executing at the headend of the videoprogramming distributor, with the decrypted content to generate a newdata stream; and at a video programming distributor network: determininga second DRM protocol compatible with the first client device;encrypting, via a conditional-access encoder, the new data stream usingthe second DRM protocol compatible with the first client device; andtransmitting, to the first client device, the data as encrypted by theconditional-access encoder.
 20. A non-transitory computer-readablestorage medium storing one or more programs for execution by one or moreprocessors at a headend of a video programming distributor hosting aplurality of virtual set-top applications, each virtual set-topapplication corresponding to a client device, the one or more programsincluding instructions for: at a first virtual set-top application ofthe plurality of virtual set-top applications, the first virtual set-topapplication corresponding to a first client device: receiving encryptedcontent from a content provider, wherein the content provider isdistinct from the video programming distributor; decrypting theencrypted content in accordance with a first Digital Rights Management(DRM) protocol used by the content provider; modifying the decryptedcontent, including blending a user-interface overlay, provided by aplayback application executing at the headend of the video programmingdistributor, with the decrypted content to generate a new data stream;and at a video programming distributor network: determining a second DRMprotocol compatible with the first client device; encrypting, via aconditional-access encoder, the new data stream using the second DRMprotocol compatible with the first client device; and transmitting, tothe first client device, the data as encrypted by the conditional-accessencoder.